In the field of distributed computing, questions of how best to allow multiple users access to a distributed database naturally arise. The answers change depending upon the design goals of the system and the expectations of its users.
In some system that are designed to accommodate the shared access to data among a number of users, some form of data "replication" is typically implemented. To achieve data replication, some systems are partitioned into a number of data "servers"--each server having a complete replica of the system database. These servers process requests from a number of "clients". Typically, client requests come in the form of Reads and Writes to the system database.
Replication of data allows flexibility and availability to clients that are mobile. One characteristic of mobile clients is that they sometimes disconnect from the system--only to reconnect at a later time with different servers than which they were previously connected. If data is completely (and perfectly) replicated across all servers, then a mobile client will always have access to the same system data as long as it can connect to at least one server.
However, the cost of "perfect" replication may be prohibitive--especially in systems that have large numbers of clients and servers. Any change (due to a Write) effected by a client necessarily needs to be immediately propagated to all system servers to ensure perfect replication. If the updates are not "immediately" propagated throughout the system, there exists the possibility that some client will access a data item at a server that has not as yet been updated--thus violating the perfection of the replication.
As a practical matter, perfection, as a system goal, is impossible. Different schemes for the relaxation of this condition have emerged. At one end of the spectrum, "strongly consistent" distributed database provide that changes are either atomically updated throughout the system or provide for some type of server-initiated callbacks when inconsistencies occur. Although strongly consistent systems provide a high degree of data consistency, the price often paid is availability. For example, a client of a strongly consistent database requesting data that has recently been updated may have access blocked to that data until it has been updated across all servers.
At the other end, "weakly" consistent databases would allow access to servers and data that may not contain all system updates. Such systems typically are characterized by the "lazy" propagation of updates between servers (i.e. updated servers propagate updates to other servers over time); thus the possibility exists for clients to see inconsistent values when reading data from different replicas. Despite this disadvantage, weakly consistent systems are popular due to their high-availability, good scalability, and simplicity of design. These advantages arise from the ability to allow reads and writes to be performed with little or no synchronization among replicas.
More recently, the use of weakly consistent replicated data has been driven by the needs of mobile computing applications. For example, disconnected users may want to read and update data copied onto their portable computers even if they did not have the foresight to commit it before either a voluntary or an involuntary disconnection occurred. Also, the presence of slow or expensive communications links in the system can make maintaining closely synchronized copies of data difficult or uneconomical.
Unfortunately, the lack of guarantees concerning the ordering of read and write operations in weakly consistent systems can confuse users and applications. A user may read some value for a data item and then later read an older value. Similarly, a user may update some data item based on reading some other data, while others read the updated item without seeing the data on which it is based. A serious problem with weakly consistent systems is that inconsistencies can appear even when only a single user or application is making data modifications. For example, a mobile client of a distributed database system could issue a write at one server, and later issue a read at a different server. The client would see inconsistent results unless the two servers had synchronized with one another sometime between the two operations.
Because data availability and data consistency are sometimes mutually exclusive goals, systems have attempted to strike some form of accommodation between the two as a system design choice. However, because a system generally supports a disparate number of clients, each with their own independent needs for security and availability, one system-wide, imposed solution to this trade-off is not desirable from a client's perspective. Some clients may want more data consistency to the detriment of availability while others prefer to access some copy of data--even though that may mean occasionally getting an inconsistent (or not "up-to-date") version.
Thus, there is a need to provide a mechanism to allow clients of a replicated database to choose the balance of data consistency and data availability for themselves. Additionally, one client's choice should be independent from the choices of other clients.
Therefore, it is an object of the present invention to provide individual clients a mechanism by which each respective client can select the level of data consistency according to its own needs and purposes.
It is an additional object of certain aspects of the present invention to have this selection of a client's consistency to be as independent as possible from the selection of other clients.